Python srauto ribojimas: žetonų kibiras prieš slenkantįjį langą – išsamus vadovas

Šiandieniniame tarpusavyje susijusiame pasaulyje patikimos API yra labai svarbios programų sėkmei. Tačiau nekontroliuojama prieiga prie API gali sukelti serverio perkrovą, paslaugų pablogėjimą ir net atsisakymo aptarnauti (DoS) atakas. Srauto ribojimas yra gyvybiškai svarbus metodas, skirtas apsaugoti jūsų API apribojant užklausų, kurias vartotojas ar paslauga gali pateikti per tam tikrą laikotarpį, skaičių. Šiame straipsnyje nagrinėjami du populiarūs srauto ribojimo algoritmai Python: žetonų kibiras ir slenkantysis langas, pateikiant išsamų palyginimą ir praktinių įgyvendinimo pavyzdžių.

Kodėl srauto ribojimas yra svarbus

Srauto ribojimas siūlo daug privalumų, įskaitant:

• Piktnaudžiavimo prevencija: apriboja kenkėjiškus vartotojus ar robotus, užkraunančius jūsų serverius per dideliu užklausų skaičiumi.
• Sąžiningo naudojimo užtikrinimas: tolygiai paskirsto išteklius tarp vartotojų, užkertant kelią vienam vartotojui monopolizuoti sistemą.
• Infrastruktūros apsauga: apsaugo jūsų serverius ir duomenų bazes nuo perkrovos ir gedimo.
• Išlaidų kontrolė: apsaugo nuo netikėtų išteklių suvartojimo šuolių, o tai lemia išlaidų sutaupymą.
• Našumo gerinimas: palaiko stabilų našumą, užkertant kelią išteklių išeikvojimui ir užtikrinant pastovų atsako laiką.

Srauto ribojimo algoritmų supratimas

Yra keletas srauto ribojimo algoritmų, kurių kiekvienas turi savo stipriąsias ir silpnąsias puses. Mes sutelksime dėmesį į du dažniausiai naudojamus algoritmus: žetonų kibirą ir slenkantįjį langą.

1. Žetonų kibiro algoritmas

Žetonų kibiro algoritmas yra paprastas ir plačiai naudojamas srauto ribojimo metodas. Jis veikia išlaikant "kibirą", kuriame laikomi žetonai. Kiekvienas žetonas reiškia leidimą pateikti vieną užklausą. Kibiras turi didžiausią talpą, o žetonai į kibirą pridedami fiksuotu greičiu.

Kai gaunama užklausa, srauto ribotuvas patikrina, ar kibire yra pakankamai žetonų. Jei yra, užklausa leidžiama, o atitinkamas žetonų skaičius pašalinamas iš kibiro. Jei kibiras tuščias, užklausa atmetama arba atidedama, kol atsiras pakankamai žetonų.

Žetonų kibiro įgyvendinimas Python

Štai pagrindinis žetonų kibiro algoritmo Python įgyvendinimas naudojant threading modulį lygiagretumui valdyti:

import time
import threading

class TokenBucket:
    def __init__(self, capacity, fill_rate):
        self.capacity = float(capacity)
        self._tokens = float(capacity)
        self.fill_rate = float(fill_rate)
        self.last_refill = time.monotonic()
        self.lock = threading.Lock()

    def _refill(self):
        now = time.monotonic()
        delta = now - self.last_refill
        tokens_to_add = delta * self.fill_rate
        self._tokens = min(self.capacity, self._tokens + tokens_to_add)
        self.last_refill = now

    def consume(self, tokens):
        with self.lock:
            self._refill()
            if self._tokens >= tokens:
                self._tokens -= tokens
                return True
            return False

# Pavyzdinis naudojimas
bucket = TokenBucket(capacity=10, fill_rate=2)  # 10 žetonų, papildymas 2 žetonais per sekundę

for i in range(15):
    if bucket.consume(1):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(0.2)

Paaiškinimas:

• TokenBucket(capacity, fill_rate): inicializuoja kibirą didžiausia talpa ir papildymo greičiu (žetonai per sekundę).
• _refill(): papildo kibirą žetonais pagal laiką, praėjusį nuo paskutinio papildymo.
• consume(tokens): bando sunaudoti nurodytą žetonų skaičių. Grąžina True, jei pavyko (užklausa leidžiama), False priešingu atveju (užklausos srautas ribojamas).
• Sriegių užraktas: naudoja sriegių užraktą (self.lock), kad užtikrintų sriegių saugumą lygiagrečiose aplinkose.

Žetonų kibiro pranašumai

• Paprasta įgyvendinti: gana paprasta suprasti ir įgyvendinti.
• Avarijų valdymas: gali valdyti atsitiktinius srauto šuolius, jei kibire yra pakankamai žetonų.
• Konfigūruojamas: talpą ir papildymo greitį galima lengvai reguliuoti, kad atitiktų konkrečius reikalavimus.

Žetonų kibiro trūkumai

• Nėra visiškai tikslus: dėl papildymo mechanizmo gali leisti šiek tiek daugiau užklausų nei sukonfigūruotas greitis.
• Parametrų derinimas: reikia atidžiai parinkti talpą ir papildymo greitį, kad būtų pasiektas norimas srauto ribojimo elgesys.

2. Slenkančiojo lango algoritmas

Slenkančiojo lango algoritmas yra tikslesnis srauto ribojimo metodas, kuris padalija laiką į fiksuoto dydžio langus. Jis seka užklausų, pateiktų kiekviename lange, skaičių. Kai gaunama nauja užklausa, algoritmas patikrina, ar užklausų skaičius dabartiniame lange viršija limitą. Jei taip, užklausa atmetama arba atidedama.

"Slenkantis" aspektas atsiranda dėl to, kad langas juda pirmyn laike, kai gaunamos naujos užklausos. Kai dabartinis langas baigiasi, prasideda naujas langas ir skaičius iš naujo nustatomas. Yra du pagrindiniai slenkančiojo lango algoritmo variantai: slenkantis žurnalas ir fiksuoto lango skaitiklis.

2.1. Slenkantis žurnalas

Slenkančiojo žurnalo algoritmas palaiko kiekvienos užklausos, pateiktos per tam tikrą laiko langą, žurnalą su laiko žymėmis. Kai gaunama nauja užklausa, jis susumuoja visas žurnale esančias užklausas, kurios patenka į langą, ir palygina tai su srauto limitu. Tai yra tikslu, tačiau gali būti brangu atminties ir apdorojimo galios požiūriu.

2.2. Fiksuoto lango skaitiklis

Fiksuoto lango skaitiklio algoritmas padalija laiką į fiksuotus langus ir kiekvienam langui palaiko skaitiklį. Kai gaunama nauja užklausa, algoritmas padidina dabartinio lango skaitiklį. Jei skaitiklis viršija limitą, užklausa atmetama. Tai paprasčiau nei slenkantis žurnalas, tačiau tai gali leisti užklausų sprogimą dviejų langų ribose.

Slenkančiojo lango įgyvendinimas Python (fiksuoto lango skaitiklis)

Štai Python slenkančiojo lango algoritmo įgyvendinimas naudojant fiksuoto lango skaitiklio metodą:

import time
import threading

class SlidingWindowCounter:
    def __init__(self, window_size, max_requests):
        self.window_size = window_size  # sekundės
        self.max_requests = max_requests
        self.request_counts = {}
        self.lock = threading.Lock()

    def is_allowed(self, client_id):
        with self.lock:
            current_time = int(time.time())
            window_start = current_time - self.window_size

            # Išvalyti senas užklausas
            self.request_counts = {ts: count for ts, count in self.request_counts.items() if ts > window_start}

            total_requests = sum(self.request_counts.values())

            if total_requests < self.max_requests:
                self.request_counts[current_time] = self.request_counts.get(current_time, 0) + 1
                return True
            else:
                return False


# Pavyzdinis naudojimas
window_size = 60  # 60 sekundžių
max_requests = 10  # 10 užklausų per minutę
rate_limiter = SlidingWindowCounter(window_size, max_requests)

client_id = "user123"

for i in range(15):
    if rate_limiter.is_allowed(client_id):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(5)

Paaiškinimas:

• SlidingWindowCounter(window_size, max_requests): inicializuoja lango dydį (sekundėmis) ir didžiausią užklausų skaičių, leidžiamą lange.
• is_allowed(client_id): patikrina, ar klientui leidžiama pateikti užklausą. Jis išvalo senas užklausas už lango ribų, susumuoja likusias užklausas ir padidina dabartinio lango skaičių, jei limitas neviršijamas.
• self.request_counts: žodynas, kuriame saugomos užklausų laiko žymos ir jų skaičius, leidžiantis apibendrinti ir išvalyti senesnes užklausas
• Sriegių užraktas: naudoja sriegių užraktą (self.lock), kad užtikrintų sriegių saugumą lygiagrečiose aplinkose.

Slenkančiojo lango pranašumai

• Tikslesnis: užtikrina tikslesnį srauto ribojimą nei žetonų kibiras, ypač slenkančiojo žurnalo įgyvendinimas.
• Apsaugo nuo ribinių sprogimų: sumažina sprogimų galimybę dviejų laiko langų ribose (efektyviau naudojant slenkantįjį žurnalą).

Slenkančiojo lango trūkumai

• Sudėtingesnis: sudėtingiau įgyvendinti ir suprasti, palyginti su žetonų kibiru.
• Didesnė našta: gali turėti didesnę naštą, ypač slenkančiojo žurnalo įgyvendinimas, dėl poreikio saugoti ir apdoroti užklausų žurnalus.

Žetonų kibiras prieš slenkantįjį langą: išsamus palyginimas

Štai lentelė, apibendrinanti pagrindinius skirtumus tarp žetonų kibiro ir slenkančiojo lango algoritmų:

Funkcija	Žetonų kibiras	Slenkantis langas
Sudėtingumas	Paprastesnis	Sudėtingesnis
Tikslumas	Mažiau tikslus	Tikslesnis
Avarijų valdymas	Geras	Geras (ypač slenkantis žurnalas)
Našta	Mažesnė	Didesnė (ypač slenkantis žurnalas)
Įgyvendinimo pastangos	Lengvesnis	Sunkesnis

Tinkamo algoritmo pasirinkimas

Žetonų kibiro ir slenkančiojo lango pasirinkimas priklauso nuo jūsų konkrečių reikalavimų ir prioritetų. Apsvarstykite šiuos veiksnius:

• Tikslumas: jei jums reikia labai tikslaus srauto ribojimo, paprastai pirmenybė teikiama slenkančiojo lango algoritmui.
• Sudėtingumas: jei paprastumas yra prioritetas, žetonų kibiro algoritmas yra geras pasirinkimas.
• Našumas: jei našumas yra labai svarbus, atidžiai apsvarstykite slenkančiojo lango algoritmo naštą, ypač slenkančiojo žurnalo įgyvendinimą.
• Avarijų valdymas: abu algoritmai gali valdyti srauto šuolius, tačiau slenkantysis langas (slenkantis žurnalas) užtikrina nuoseklesnį srauto ribojimą esant didelėms apkrovoms.
• Mastelio keitimas: labai keičiamoms sistemoms apsvarstykite galimybę naudoti paskirstytus srauto ribojimo metodus (aptariami toliau).

Daugeliu atvejų žetonų kibiro algoritmas užtikrina pakankamą srauto ribojimo lygį su palyginti mažomis įgyvendinimo sąnaudomis. Tačiau programoms, kurioms reikia tikslesnio srauto ribojimo ir kurios gali toleruoti didesnį sudėtingumą, slenkančiojo lango algoritmas yra geresnis pasirinkimas.

Paskirstytas srauto ribojimas

Paskirstytose sistemose, kuriose kelis serveriai tvarko užklausas, dažnai reikalingas centralizuotas srauto ribojimo mechanizmas, siekiant užtikrinti nuoseklų srauto ribojimą visuose serveriuose. Paskirstytam srauto ribojimui galima naudoti kelis metodus:

• Centralizuota duomenų saugykla: naudokite centralizuotą duomenų saugyklą, tokią kaip Redis arba Memcached, kad saugotumėte srauto ribojimo būseną (pvz., žetonų skaičių arba užklausų žurnalus). Visi serveriai pasiekia ir atnaujina bendrą duomenų saugyklą, kad įgyvendintų srauto limitus.
• Apkrovos balanso srauto ribojimas: sukonfigūruokite savo apkrovos balansą, kad jis atliktų srauto ribojimą pagal IP adresą, vartotojo ID ar kitus kriterijus. Šis metodas gali sumažinti srauto ribojimą nuo jūsų programų serverių.
• Atskiras srauto ribojimo tarnyba: sukurkite atskirą srauto ribojimo tarnybą, kuri tvarko visas srauto ribojimo užklausas. Šią tarnybą galima nepriklausomai keisti ir optimizuoti našumui.
• Kliento pusės srauto ribojimas: nors tai nėra pagrindinė apsauga, informuokite klientus apie jų srauto limitus per HTTP antraštes (pvz., X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Tai gali paskatinti klientus patiems riboti srautą ir sumažinti nereikalingų užklausų skaičių.

Štai pavyzdys, kaip naudoti Redis su žetonų kibiro algoritmu paskirstytam srauto ribojimui:

import redis
import time

class RedisTokenBucket:
    def __init__(self, redis_client, bucket_key, capacity, fill_rate):
        self.redis_client = redis_client
        self.bucket_key = bucket_key
        self.capacity = capacity
        self.fill_rate = fill_rate

    def consume(self, tokens):
        now = time.time()
        capacity = self.capacity
        fill_rate = self.fill_rate

        # Lua scenarijus atomiškai atnaujinti žetonų kibirą Redis
        script = '''
        local bucket_key = KEYS[1]
        local capacity = tonumber(ARGV[1])
        local fill_rate = tonumber(ARGV[2])
        local tokens_to_consume = tonumber(ARGV[3])
        local now = tonumber(ARGV[4])

        local last_refill = redis.call('get', bucket_key .. ':last_refill')
        if not last_refill then
            last_refill = now
            redis.call('set', bucket_key .. ':last_refill', now)
        else
            last_refill = tonumber(last_refill)
        end

        local tokens = redis.call('get', bucket_key .. ':tokens')
        if not tokens then
            tokens = capacity
            redis.call('set', bucket_key .. ':tokens', capacity)
        else
            tokens = tonumber(tokens)
        end

        -- Papildyti kibirą
        local time_since_last_refill = now - last_refill
        local tokens_to_add = time_since_last_refill * fill_rate
        tokens = math.min(capacity, tokens + tokens_to_add)

        -- Sunaudoti žetonus
        if tokens >= tokens_to_consume then
            tokens = tokens - tokens_to_consume
            redis.call('set', bucket_key .. ':tokens', tokens)
            redis.call('set', bucket_key .. ':last_refill', now)
            return 1  -- Sėkmė
        else
            return 0  -- Srautas ribojamas
        end
        '''

        # Vykdyti Lua scenarijų
        consume_script = self.redis_client.register_script(script)
        result = consume_script(keys=[self.bucket_key], args=[capacity, fill_rate, tokens, now])
        return result == 1


# Pavyzdinis naudojimas
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)
bucket = RedisTokenBucket(redis_client, bucket_key='my_api:user123', capacity=10, fill_rate=2)

for i in range(15):
    if bucket.consume(1):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(0.2)

Svarbūs aspektai paskirstytoms sistemoms:

• Atomiškumas: užtikrinkite, kad žetonų suvartojimo arba užklausų skaičiavimo operacijos būtų atomiškos, kad būtų išvengta lenktynių sąlygų. Redis Lua scenarijai suteikia atomines operacijas.
• Latencija: sumažinkite tinklo latenciją, kai pasiekiate centralizuotą duomenų saugyklą.
• Mastelio keitimas: pasirinkite duomenų saugyklą, kuri gali keisti mastelį, kad apdorotų numatomą apkrovą.
• Duomenų nuoseklumas: spręskite galimas duomenų nuoseklumo problemas paskirstytose aplinkose.

Geriausia srauto ribojimo praktika

Štai keletas geriausios praktikos, kurios reikia laikytis įgyvendinant srauto ribojimą:

• Nustatykite srauto ribojimo reikalavimus: nustatykite tinkamus srauto limitus skirtingiems API galiniams punktams ir vartotojų grupėms, atsižvelgdami į jų naudojimo modelius ir išteklių suvartojimą. Apsvarstykite galimybę pasiūlyti pakopinę prieigą pagal prenumeratos lygį.
• Naudokite prasmingus HTTP būsenos kodus: grąžinkite atitinkamus HTTP būsenos kodus, kad nurodytumėte srauto ribojimą, pvz., 429 Per daug užklausų.
• Įtraukite srauto limito antraštes: įtraukite srauto limito antraštes į savo API atsakymus, kad informuotumėte klientus apie jų dabartinę srauto limito būseną (pvz., X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset).
• Pateikite aiškius klaidų pranešimus: pateikite informatyvius klaidų pranešimus klientams, kai jų srautas ribojamas, paaiškindami priežastį ir siūlydami, kaip išspręsti problemą. Pateikite kontaktinę informaciją, skirtą palaikymui.
• Įgyvendinkite sklandų pablogėjimą: kai įgyvendinamas srauto ribojimas, apsvarstykite galimybę teikti pablogintą paslaugą, užuot visiškai blokuojant užklausas. Pavyzdžiui, pasiūlykite talpykloje saugomus duomenis arba sumažintą funkcionalumą.
• Stebėkite ir analizuokite srauto ribojimą: stebėkite savo srauto ribojimo sistemą, kad nustatytumėte galimas problemas ir optimizuotumėte jos našumą. Analizuokite naudojimo modelius, kad prireikus pakoreguotumėte srauto limitus.
• Apsaugokite savo srauto ribojimą: neleiskite vartotojams apeiti srauto limitų, patvirtindami užklausas ir įgyvendindami atitinkamas saugumo priemones.
• Dokumentuokite srauto limitus: aiškiai dokumentuokite savo srauto ribojimo politiką savo API dokumentacijoje. Pateikite kodo pavyzdį, rodantį klientams, kaip tvarkyti srauto limitus.
• Išbandykite savo įgyvendinimą: kruopščiai išbandykite savo srauto ribojimo įgyvendinimą įvairiomis apkrovos sąlygomis, kad įsitikintumėte, jog jis veikia tinkamai.
• Apsvarstykite regioninius skirtumus: diegdami visame pasaulyje, atsižvelkite į regioninius tinklo latencijos ir vartotojų elgesio skirtumus. Gali tekti pakoreguoti srauto limitus pagal regioną. Pavyzdžiui, mobiliųjų įrenginių rinkai, tokiai kaip Indija, gali reikėti skirtingų srauto limitų, palyginti su didele pralaidumo zona, tokia kaip Pietų Korėja.

Realūs pavyzdžiai

• Twitter: Twitter plačiai naudoja srauto ribojimą, kad apsaugotų savo API nuo piktnaudžiavimo ir užtikrintų sąžiningą naudojimą. Jie pateikia išsamią dokumentaciją apie savo srauto limitus ir naudoja HTTP antraštes, kad informuotų kūrėjus apie jų srauto limito būseną.
• GitHub: GitHub taip pat naudoja srauto ribojimą, kad apsaugotų nuo piktnaudžiavimo ir palaikytų savo API stabilumą. Jie naudoja IP pagrįstus ir vartotojo pagrįstus srauto limitus.
• Stripe: Stripe naudoja srauto ribojimą, kad apsaugotų savo mokėjimų apdorojimo API nuo sukčiavimo ir užtikrintų patikimą paslaugą savo klientams.
• E. komercijos platformos: daugelis e. komercijos platformų naudoja srauto ribojimą, kad apsisaugotų nuo robotų atakų, kurios bando nubraukti informaciją apie produktus arba atlikti atsisakymo aptarnauti atakas per staigius išpardavimus.
• Finansų įstaigos: finansų įstaigos įgyvendina srauto ribojimą savo API, kad apsaugotų nuo neteisėtos prieigos prie slaptų finansinių duomenų ir užtikrintų atitiktį reguliavimo reikalavimams.

Išvada

Srauto ribojimas yra esminis metodas, skirtas apsaugoti jūsų API ir užtikrinti jūsų programų stabilumą ir patikimumą. Žetonų kibiro ir slenkančiojo lango algoritmai yra dvi populiarios parinktys, kurių kiekviena turi savo stipriąsias ir silpnąsias puses. Suprasdami šiuos algoritmus ir laikydamiesi geriausios praktikos, galite veiksmingai įgyvendinti srauto ribojimą savo Python programose ir sukurti atsparesnes ir saugesnes sistemas. Atminkite, kad reikia atsižvelgti į savo konkrečius reikalavimus, atidžiai pasirinkti tinkamą algoritmą ir stebėti savo įgyvendinimą, kad įsitikintumėte, jog jis atitinka jūsų poreikius. Kai jūsų programa keičiasi, apsvarstykite galimybę naudoti paskirstytus srauto ribojimo metodus, kad išlaikytumėte nuoseklų srauto ribojimą visuose serveriuose. Nepamirškite aiškaus bendravimo su API vartotojais svarbos per srauto limito antraštes ir informatyvius klaidų pranešimus.